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Rules and Regulations for the 
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The status of this Rule set is amended as shown and is now to be read in conjunction with this and prior Notices. 
Any corrigenda included in the Notice are effective immediately. 


Please note that corrigenda amends to paragraphs, Tables and Figures are not shown in their entirety. 
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Register 


Volume 2, Part 1, 
Chapter 3 


Requirements for Design, Construction, Installation and Sea Trials of 
Engineering Systems 


z Section 21 
Software in systems, machinery and equipment 


21.1 Goal, functional requirements and applicability 


21.1.1 Goal: The use of software in systems, machinery and equipment is not to compromise the functionality or safety of those 
systems, machinery and equipment. 


21.1.2 Functional requirements: The safety risk arising from the use of software in systems, machinery and equipment is to be 
appropriately managed by ensuring that software safety requirements are identified and satisfied. A diagrammatic view of the software 
rules process is shown in Figure 3.21.1 Software rules process diagram — Machinery/Engineering system requirements and Figure 3.21.2 
Software rules process diagram — Software production requirements. 


21.1.3 Applicability: These rules apply to all systems, machinery and equipment mentioned in the remaining Parts of Vol 2 Machinery 
and Engineering Systems of these Rules where software is used as an implementation technology. They also apply to software where 
the software is used in a role that has an identified impact upon the safety of the ship. Instances where the operational performance of 
the software can only be characterised accurately in probabilistic terms, e.g. Machine Learning or Artificial Intelligence based systems, 
will require further and more extensive consideration beyond the scope of this set of Rules. See also Vol 2, Pt 9, Ch 8, 5.6 Programmable 
electronic systems — Additional requirements for the production of software. 


Machinery / Engineering systems requirements 


Key 


Identify 
system safety 
hazards related 
to software 


Input and 
output documents 


| Linkage to | 
another image 


System definition 


Establish system safety 
hazards resulting from Documented system safety hazard 

»| unintended behaviour of assessment related to software 
software 


Risk manangement 


standard 


System catagories Categorise system 
according to failure effects 


Relevant classification 
requirements 


Consider alternative means 
independent of software 
for essential services 


Specify software safety 
requirements 


Software safety 
requirements specification 


Consider alternative means 
independent of software for 
emergency stop & safety critical functions 


Relevant statutory requirements 


Assign control category 


Software control categories 
to software components 


Determine Level of 
rigour tasks for 
software components 


Software safety criticality matrix 


Select software 
production standard 


Technical justification 
of the 
Selected software production standard 


Lal 7 
rc 4 | To Software production , 
| From Software production requirements 


| requirements See Note 1 
See Note 2 = 


Note 1 See continuation in Figure 3.21.2 Software rules process diagram — Software Production Requirements 
Note 2 Continued from Figure 3.21.2 Software rules process diagram — Software production requirements 
Figure 3.21.1 Software rules process diagram — Machinery/Engineering system requirements 
2 


Software production requirements 
Key 


7 ‘ To P ‘ 2 Input and 
Machinery / Engineering l output documents | 
| systems requirements | 
, See Note 2 7 TT From 7 
l Machinery / Engineering | 


systems requirements 7 = 


L See Note 1 4 | Linkage to 


another image | 
c ~ 


Plan for the production 
of software 
including timeline 
and key hold points 


Software production 
standard and technical 
justification from design authority; 


Produce plan for 
the production of software 


Software safety 
requirements Manage software 

Specification development to satisfy 

software safety requirement 


Software 
production standard 


Software safety 
requirements 
specification 


anage software verification 
and validation to 
ensure that software 
safety requirements 
have been satisfied 


Software 
production standard 


Demonstrate software safety 
requirements are satisfied 
using engineering safety 
justification. 


Software 
production standard 


Engineering and safety 
justification report 
and supporting evidence 


The software producer is 
to communicate this to 
the design authority and 
other affected stakeholders 


Are all software 
safety requirements 
implemented? 


Certification documents 


Produce certification 
documents 


Produce engineering safety 
justification / evidence 


Engineering safety 
justification / evidence 


Design authority is to 
create and maintain 
hardware and software registry 


Registry of hardware & software 


End 


Note 1 Continued from Figure 3.21.1 Software rules process diagram — Machinery/Engineering system requirements 
Note 2 See continuation in Figure 3.21.1 Software rules process diagram — Machinery/Engineering system requirements 
Figure 3.21.2 Software rules process diagram — Software production requirements 


21.2 Definitions 


21.2.1 Software: Intellectual creation comprising the programs, procedures, data, rules and any associated documentation relating to 
the operation of a data processing system or complex hardware, where complex hardware includes but is not limited to custom micro- 
coded components including application specific integrated circuits (ASIC), programmable logic devices (PLD), field programmable gate 
arrays (FPGA) or similar electronic technologies. 


21.2.2 Software module: A standalone executable element of code that provides specific and closely coupled functionality. 


21.2.3 System Design Authority: Person or organisation that is responsible for the design of the system. In this context, the single 
designated party responsible for system functionality in its entirety at each lifecycle stage, from concept to disposal. 


21.2.4 Software producer: The organisation responsible for producing and/or maintaining the software module. 


21.2.5 System safety hazards: The hazards to the safe operation of the ship resulting from failure or unintended behaviour of a system, 
item of machinery or equipment which incorporates software. 


21.2.6 Software safety requirements: Requirements placed on the software which define what the software must do and what the 
software must not do to address system safety hazards including the degree of reliance placed upon the software. 


21.2.7 Level of rigour task: A specification of the depth and breadth of software analysis and verification activities necessary to provide 
a sufficient level of confidence that a software module will function as required. 


21.2.8 Software Production Standard: An International or National Standard to be applied to the production of software 
21.3 Performance requirements 


21.3.1 The System Design Authority is to identify and document the system safety hazards related to software, categorise the system, 
and assign the software control categories to each software module. It is then to identify the resulting level of rigour tasks to be applied 
to each software module utilising processes identified in this Section of these Rules, or an equivalent process acceptable to LR. The 
resulting software safety requirements and any safety-related statutory and classification software requirements are to be documented 
and provided to the software producer. 


21.3.2 Software safety requirements are to be derived from the identified system safety hazards and their categorisations. 
Consideration is to be given to the effects of failure of a software module or unintended behaviour of a software module which could 
credibly 

(a) result in a system safety hazard; 

(b) impair the mitigation of a system safety hazard; or 

(c) impair recovery after a system safety hazard has occurred. 


The traceability between software safety requirements and system safety hazards is to be documented as part of this process. The 
establishment of a Systems Risk Register is to be considered to assist the identification of system safety hazards and tracing the resulting 
software safety requirements. Where the risk assessment technique required by Vol 2, Pt 1, Ch 3, 21.3.3 Performance requirements 
requires the creation of a Systems Risk Register, this is to be submitted for information. 


21.3.3 System safety hazards resulting from failure or unintended behaviour of software in systems, machinery or equipment 
incorporating software modules are to be established in accordance with IEC/ISO 31010 Risk Management — Risk Assessment 
techniques and/or an appropriate standard acceptable to LR. 


21.3.4 Where two systems or items of machinery are intended to function as redundant components, the risk of the software introducing 
common mode failures that result in the loss or unintended behaviour of both components is to be considered as part of the hazard 
assessment. 


21.3.5 System safety hazards are to be identified and the system categorised in accordance with the failure effects in Table 3.21.1 
System categories or an equivalent categorisation acceptable to LR. 


Table 3.21.1 System categories 
Category Effects Typical System Functionality 

| Those systems, failure of which will not lead to | Monitoring function for informational or 
unsafe conditions for human safety, safety of the | administrative tasks 

ship and/or threat to the environment. 


Those systems, failure of which could eventually 
lead to unsafe conditions for human safety, safety 
of the ship and/or threat to the environment. 


Alert and monitoring functions 

Control functions which are necessary to 
maintain the ship in its normal operational 
and habitable conditions 


Those systems, failure of which could immediately 
lead to unsafe conditions for human safety, safety 
of the ship and/or threat to the environment. 


Control functions for maintaining the 
vessel’s propulsion and steering 
Protection and safety functions 


Those systems, failure of which would usually 
result in loss of the ship, death, and/or irreversible 
significant environmental impact. 


Control systems for which manual 
intervention to avert danger in the event of 
failure or malfunction is not possible 


21.3.6 Software modules are to be assigned a software control category in accordance with the module’s degree of control over the 
system hardware, sub-systems or components as given in Table 3.21.2 Software control categories or an equivalent categorisation 
acceptable to LR. 


Table 3.21.2 Software control categories 
Software Control | Name Description 
Category 
1 Full Control Authority Software module that exercises autonomous control 
authority over potentially safety-significant hardware 
systems, sub-systems or components without the possibility 
of predetermined safe detection and intervention by a 
control entity to preclude the occurrence of a hazard. 
2 Supported Control Software module that exercises control authority over 
Authority potentially safety-significant hardware systems, sub- 
systems or components, allowing time for predetermined 
safe detection and intervention by independent safety 
mechanisms to mitigate or control the hazard. 


Software module that displays information requiring 
immediate Operator intervention to execute a 
predetermined action for mitigation of or control over a 
hazard. Software exception, failure, fault or delay will allow, 
or fail to prevent, hazard occurrence. 


3 Shared Control Authority Software module that issues commands over safety- 
significant hardware systems, sub-systems or components 
requiring a control entity to complete the command function. 
The system detection and functional reaction includes 
redundant, independent fault tolerant mechanisms for each 
defined hazardous condition. 


Software module that generates information used to make 
critical decisions. The system includes several redundant, 
independent fault tolerant mechanisms for each hazardous 
condition, detection and display. 


4 Influential Software module that generates information used to make 
decisions by the Operator but does not require Operator 
action to avoid a hazard. 


21.3.7 The Level of rigour tasks to be applied to each software module during production are to be determined in accordance with the 
Software safety criticality Matrix in Table 3.21.3 Software safety criticality matrix or an equivalent categorisation acceptable to LR. 


Table 3.21.3 Software safety criticality matrix 
System Category 


Software Control | | Il HT} IV 
Category 

4 SwCl 1 SwCl 1 SwCl 1 SwCl 3 

3 SwCl 1 SwCl 1 SwCl 2 SWCl 3 

2 SwCl 1 SwCl 2 SwCl 3 SwCl 4 

1 SwCl 1 SwCl 2 SwCl 4 SwCl 4 
Level of rigour tasks 

SwCl 1 Safety-specific testing. 

SwCl 2 Analysis of requirements and architecture; and conduct in-depth safety-specific testing. 

SwCl 3 Analysis of requirements, architecture and design; and conduct in-depth safety-specific 
testing. 

SwCl 4 Analysis of requirements, architecture, design and code; and conduct in-depth safety- 


specific testing. 


21.3.8 The Software Production Standard selected by the System Design Authority to develop the software must be able to evidence 
the Levels of rigour tasks as equivalent to those determined by Vol 2, Pt 1, Ch 3, 21.3 Performance requirements 21.3.7. The justification 
leading to the selection of the Software Production Standard is to be documented and is to include the tasks described in Vol 2, Pt 1, Ch 
3, 21.3 Performance requirements 21.3.1 to Vol 2, Pt 1, Ch 3, 21.3 Performance requirements 21.3.7. The evidence supporting the case 
that the required Level of rigour tasks have been undertaken is to be collated by the software producer and included within the engineering 


and safety justification required by Vol 2, Pt 9, Ch 8, 5.6 Programmable electronic systems — Additional requirements for the production 
of software 5.6.1. Software Conformity Assessment (SCA) may be used for this purpose. 


21.3.9 Where asystem or item of machinery or equipment includes more than one software module, the software safety requirements 
for each software module are to be specified separately. 


21.3.10 Where a system or item of machinery or equipment includes more than one software module, the System Design Authority is 
responsible for the successful integration and performance of the software modules. In such cases, the System Design Authority is to 
assume those responsibilities of the software producer that relate to software integration. 


Volume 2, Part 2, 
Chapter 1 
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cl Section 4 
Electronically controlled engines 


4.4 Software 


4.4.2 Appropriate safety related processes, methods, techniques and tools are to be applied to software development and 
maintenance by the Enginebuilder. Selection and application of techniques and measures in accordance with Annex A of IEC 61508-3, 
Functional safety of electrical/electronic/programmable electronic systems: Software requirements, Vol 2, Pt 1, Ch 3, 21 Software in 
systems, machinery and equipment and Vol 2, Pt 9, Ch 8, 5.6 Programmable electronic systems — Additional requirements for the 
production of software or other relevant standards or codes acceptable to LR, will generally be acceptable. 


Volume 2, Part 7 
Chapter 1 
Piping Design Requirements 


| Section 4 
Materials 
4.3 Dissimilar materials 


4.3.1 | Where materials vary for individual pipes and components that are joined in the presence of a conductive fluid they are either 
to be compatible, or electrically isolated, in order to avoid galvanic corrosion. 


rT Section 5 
Pipe joints 


5.10 Other mechanical couplings 


5.10.1 Pipe unions, compression couplings, or slip-on joints, as shown in Figure 1.5.4 Examples of mechanical joints (Part 1) and 
Figure 1.5.5 Examples of mechanical joints (Part 2), may be used if Fype-Appreved type approved for the service conditions, the pipe 
material, and the intended application. The FypeApprevat type approval is to be based on the results of testing of the actual joints. The 
acceptable use for each service is indicated in Table 1.5.3 Application of mechanical joints and dependence upon the Glass class of 
piping, with limiting pipe dimensions, working pressure and temperature, is indicated in Table 1.5.4 Application of mechanical joints 
depending on class of piping. 


(Part only shown) 
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Figure 1.5.4 Examples of mechanical joints (Part 1) 


(Part only shown) 

Table 1.5.3 Application of mechanical joints 
Systems Type of connections 

Pipe unions Compression coupling Slip-on joints 

Flammable fluids (Flash point <60° C) 
Aircraft and vehicle fuel oil lines see Notes 2 & 4 + + + 
Vent lines see Notes 2 & 3 + + oe 
Flammable fluids (Flash point > 60° C) 
Aircraft and vehicle fuel oil lines see Notes 2 & 4 + + + 
Ship’s machinery fuel oil lines see Notes 2 & 3 + + oe 
Lubricating oil lines see Notes 2 & 3 + + + 
Hydraulic oil see Notes 2 & 3 + + + 
Thermal oil see Notes 2 & 3 + + + 
Note 2. Mechani 


Slip-on joints are not accepted inside machinery spaces of category A, munition stores, or accommodation spaces. Slip-on joints 
are accepted in other machinery and service spaces provided that the joints are located in easily visible and accessible 
positions. 


Note 3. Mechanical joints thati C ire are to be of an approved fire- 
resistant type-, except when they are fitted on open ZEEE Revie little or no fie rene as defined in SOLAS Chapter II-2, 
Regulation 9.2.3.3.2.2(10). 


Note 4. Mechanical joints thati 


resistant type iio nits ie sumpatieee antan cpa dccicl 


ire are to be of an approved fire- 


Existing Table 1.5.4 has been deleted and replaced by the below table. 


Table 1.5.4 Application of mechanical joints depending on class of piping 


Types of joints Classes of piping systems 

Class | Class II Class III 
Pipe unions 
Welded and brazed type +(OD<60,3mm) | +(OD<60,3 mm) iti 


Compression couplings 


Swage type - E + 
Bite type + (OD s 60,3 mm) + (OD < 60,3 mm) + 
Typical compression type +(OD<60,3mm) | +(OD<60,3 mm) fi 
Flared type + (OD s 60,3 mm) + (OD s 60,3 mm) + 
Press type - - iH 


Slip-on joints 


Machine grooved type + + + 
Grip type : g + 
Slip type : + + 
KEY 


+ Application is allowed 


- Application is not allowed 


5.10.12 The type or location of pipe joints may be limited by the shock policy requirements defined by the Naval Administration. The use 
of mechanical joints is to be considered against the shock requirements. 


Volume 2, Part 7, 
Chapter 3 
Machinery Piping Systems 


7 Section 4 
Fuel oil pumps, pipes, fittings, tanks, etc. 


4.11 _ Filling arrangements 


4.11.2 Provision is to be made against everpressure overpressure in the filling pipelines_ard. Where any relief valve(s) are fitted for 
this purpose4s, they are to discharge to an overflow tank or other safe position. 


Volume 2, Part 7, 
Chapter 5 
Ship Type Piping Systems 


= Section 11 
Hydraulic power actuating systems 


11.7 Pipes conveying oil 


The locations of pipe joints, valves, and other potential leak paths in piping systems for flammable hydraulic fluids are to be arranged so 
that, in the event of a leak, fluid will not come into contact with hot surfaces, machinery air intakes, electrical equipment or other sources 
of ignition. 


11.7.2 Pipes conveying hydraulic oil under pressure are to be of seamless steel or other approved material-having flanged or welded 
joints, and are to be placed in sight above the platform in well lit and readily accessible parts of the machinery spaces. Fhe numberof 


flanged jointsistobe kepttoa 


Volume 2, Part 9, 
Chapter 1 


General Requirements for the Design and Construction of Electrotechnical 
Systems 


7 Section 1 
General requirements 


1.3 Definitions 


1.3.35 Programmable electronic system: a system based on one or more programmable electronic devices, often connected to (and 
including) input devices (e.g. sensors) and/or output devices/final elements (e.g. actuators), for the purposes of control, protection or 
monitoring. 


1.3.36 An argument is used to show how the components directly underlying it relate to a claim or set of claims. See ISO 15026-2: 
Systems and software engineering — Systems software assurance, Part 2: Assurance case. 


1.3.37 A justification gives the reason that something has been used or applied. See ISO 15026-2: Systems and software engineering 
— Systems and software assurance, Part 2: Assurance case. 


1.3.38 Production of software: the process of interpreting requirements and realising those requirements as software modules by using 
suitable lifecycle steps and applying the attributes of quality, safety and other management systems. Production of software includes all 
lifecycle phases from requirements to support for system integration and system testing. Where iterative or cyclical lifecycles are used, 
the production of software includes all iterations or cycles. The production of software includes tailored lifecycle phases where existing 
or modified software is used. 


1.3.39 Existing software: previously developed software that is to be used without modification that includes, but is not limited to, 
Operating system, third party communications protocols, graphics, libraries and reused supplier developed code. 


1.3.40 Modified software: software based upon an existing software but changed for the system being assessed. Modifications can 
range from setting/configuration changes to modifications that require the software to be recompiled. 


1.3.41 Software Production Standard: an International or National Standard to be applied to the production of software. 


1.3.42 Engineering system: any system that may be installed in a ship where such a system comprises one or more sub-systems, 
items of machinery or components. 


1.4 Documentation required for design review 


(Part only shown) 

1.4.21 Programmable electronic systems. {In addition to the documentation required by Vol 2, Pt 9, Ch 1, 1.4 Documentation 

required for design review 1.4.2.) the following is to be submitted: 

(i) | Software safety requirements document, see Vol 2, Pt 1, Ch 3, 21.3 Performance requirements 21.3.1. 

(j) | The engineering and safety justification and supporting evidence, see Vol 2, Pt 9, Ch 8, 5.6 Programmable electronic systems — 
Additional requirements for the production of software 5.6.3. 

(k) The certification documents for the production of software, see Vol 2, Pt 9, Ch 8, 5.6 Programmable electronic systems — 
Additional requirements for the production of software 5.6.6. 

(l) The plan for the production of software, see Vol 2, Pt 9, Ch 8, 5.6 Programmable electronic systems — Additional requirements for 
the production of software 5.6.7. 

(m) The registry of hardware and software, see Vol 2, Pt 9, Ch 8, 5.6 Programmable electronic systems — Additional requirements for 
the production of software 5.6.21. 


1.4.29 Configuration management plan. Procedures for the configuration management process applied to the control, alarm and 
safety systems intended for the machinery or equipment as defined in Vol 2, Pt 9, Ch 1, 1.4 Documentation required for design review 
1.4.2. 


1.5 Documentation required for supporting evidence 


1.5.13 For programmable electronic systems: 
(a) The Systems Risk Register, where required, see Vol 2, Pt 1, Ch 3, 21.3 Performance requirements 21.3.2. 


: Section 2 
System level requirements 


2.8 Labels, signs and notices 


2.8.5 Electrical equipment that presents an electric arc-flash hazard to personnel is to be clearly marked, see Vol 2, Pt 9, Ch 4, 5.1 
General 5.1.1. 


Volume 2, Part 9, 
Chapter 3 
Electrical Power Distribution and Equipment 


5 Section 5 
Switchgear and controlgear assemblies 


5.14 Labels 


5.14.1 The identification of individual circuits and their devices is to be made on labels of durable material. The ratings of fuses and 
settings of protective devices are also to be indicated. The warning of the presence of electric arc-flash hazards is also to be shown. 
Section and distribution boards are to be marked with the rated voltage. 


10 


Volume 2, Part 9, 
Chapter 8 
Programmable Electronic Systems 


7 Section 5 
Programmable electronic systems (PES) 


5.1 General requirements 


5.1.1 The requirements of this Section are to be complied with where control, alarm, monitoring or safety systems incorporate 
programmable electronic equipment. Mobility systems, Shie-Fype-ship type systems and safety critical systems incorporating shared 
data communication links and systems which are integrated are to comply with the additional requirements of Vol 2, Pt 9, Ch 8, 5.2 Data 
communication links, Vol 2, Pt 9, Ch 8, 5.3 Additional requirements for wireless data communication links and, Vol 2, Pt 9, Ch 8, 5.4 
Additional requirements for Mobility category and safety critical systems and Vol 2, Pt 9, Ch 8, 5.5 Additional requirements for integrated 
systems as applicable. 


5.2 Data communication links 
5.2.12 The data communication links are to be resilient as described elsewhere in this section of the rules to the accumulation of 
broadcast and multicast network traffic. The audible and visual alarms required by Vol 2, Pt 9, Ch 8, 5.2 Data communication links 5.2.6 


are to be initiated in the event of such accumulations of traffic occurring and affecting normal network performance. Demonstration of 
this resilience is to be shown by a practical test or other acceptable means appropriate to the communication link, and documented. 


5.4 Additional requirements for Mobility category and safety critical systems 


GENL 994). Alternative means of safe and effective control a are to be ae for Mobility category and safety critical systems. Back- 
up control systems are to be of diverse design, and are to operate independently of the main control system. The software is to comply 
with the requirements of Vol 2, Pt 1, Ch 3, 21 Software in systems, machinery and equipment and Vol 2, Pt 9, Ch 8, 5.6 Programmable 
electronic systems — Additional requirements for the production of software of these Rules. Alternatively, consideration may be given to 
the use of LR’s Software Conformity Assessment System — Assessment Module GEN1 (1994) or an equivalent software assessment 
acceptable to LR. 


5.4.8 Where it is intended that the programine ale electronic Sei Mine melts an emergency stop aanenolts or Seley alee 
functions, the software is to 
(4994)-comply with the requirements of vol 5 iets Ch 3; 21 Software in | systems, machinery and ania a Vol 2, Pt 9, Ch 8, 5 5 
Additional requirements for integrated systems of these Rules. Alternative proposals providing an equivalent level of system integrity will 
be subject to special consideration, e.g. fullyindependenthard-wired back-up system, redundancy with design diversity.-ete- Alternatively, 
consideration may be given to the use of LR’s Software Conformity Assessment System — Assessment Module GEN1 (1994) or an 
equivalent software assessment acceptable to LR. 


5.6 Programmable electronic systems — Additional requirements for the production of software 


5.6.1 The requirements of Vol 2, Pt 9, Ch 8, 5.6 Programmable electronic systems — Additional requirements for the production of 
software 5.6.1 to Vol 2, Pt 9, Ch 8 Programmable electronic systems — Additional requirements for the production of software 5.6.24 
apply to all software created for programmable electronic systems whose safety hazards have been classified within categories II, Ill and 
IV as defined by Vol 2, Pt 1, Ch 3, 21.3 Performance requirements 21.3.5. Alternatively, consideration may be given to the use of LR's 
Software Conformity Assessment System — Assessment Module GEN1 (1994). See also Vol 2, Pt 1, Ch 3, 21 Software in systems, 
machinery and equipment. A diagrammatic view of the software rules process is shown in Figure 8.5.1 Software rules process diagram 
— Machinery/Engineering system requirements and Figure 8.5.2 Software rules process diagram — Software production requirements. 
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Note 1 See continuation in Figure 8.5.2 Software rules process diagram — Software Production Requirements 
Note 2 Continued from Figure 8.5.2 Software rules process diagram — Software production requirements 
Figure 8.5.1 Software rules process diagram — Machinery/Engineering system requirements 
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Note 1 Continued from Figure 8.5.1 Software rules process diagram — Machinery/Engineering system requirements 
Note 2 See continuation in Figure 8.5.1 Software rules process diagram — Machinery/Engineering system requirements 


Figure 8.5.2 Software rules process diagram — Software production requirements 
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5.6.2 The production of software is to demonstrate that the software safety requirements derived from the risk assessment required 
by Vol 2, Pt 1, Ch 3, 21.3 Performance requirements 21.3.3 have been met. 


5.6.3. An engineering and safety justification is to be made and documented. This is to provide compelling, comprehensible and valid 
arguments that the intent and requirements of the Rules have been complied with, supported by a body of evidence that provides a 
compelling, comprehensible and valid demonstration that the functional requirements identified in Pt 5, Ch 1, 8.1 Goal, functional 
requirements and applicability 3.1.2 have been met. The engineering and safety justification is to be produced in accordance with ISO/IEC 
15026-2 Systems and software engineering — Systems and software assurance, Part 2: Assurance case or an alternative standard 
acceptable to LR. 


5.6.4 Where the arguments presented in the engineering and safety justification required by Vol 2, Pt 9, Ch 8, 5.6 Programmable 
electronic systems — Additional requirements for the production of software 5.6.3 are not supported by evidence, it is to be shown that 
the identified risks associated with the engineering system are mitigated by other means; alternatively, evidence is to be submitted to LR 
that the residual risk is tolerable and as low as reasonably practicable. 


5.6.5 Configuration management satisfying the requirements of ISO 10007 Quality management systems — Guidelines for 
configuration management, or an alternative standard acceptable to LR, is to be used during the production of software. 


5.6.6 Software is to be produced using a quality management system that satisfies the requirements of ISO 9001 Quality management 
systems — Requirements using the guidance of ISO 90003: Software engineering — Guidelines for the application of ISO 9001: to 
computer software or an alternative to LR. Certification documents for the production of software are to be submitted to LR. 


5.6.7 A plan for the production of software is to be formulated, documented and used to direct the production of software. If the plan 
is incorporated into another document, the strategy, and the structure of the plan, with appropriate cross-references to other 
documentation, are to be documented separately. The level of detail in the plan is expected to increase as the project progresses through 
the lifecycle phases of the production of software. The plan is to be complete with respect to each lifecycle phase before the phase is 
initiated. 


5.6.8 The plan for the production of software is to include: 

(a) all activities for the production of software, including production of the justification and supporting evidence required by Vol 2, 
Pt 9, Ch 8, 5.6 Programmable electronic systems — Additional requirements for the production of software 5.6.3; 

(b) the processes, methods, techniques and tools required by the Software Production Standard and applicable to the degree of reliance 
placed on the software by the software safety requirements; 

(c) factors which influence the introduction and mitigation of errors, such as the size, complexity and novelty of the software; 

(d) any deviations, with justification, from the requirements of the Software Production Standard; and 

(e) all activities for the creation of the documentation and testing of the system appropriate to the system category as defined by 
Vol 2, Pt 1, Ch 3, 21.3 Performance requirements 21.3.5 and Vol 2, Pt 1, Ch 3, 21.3 Performance requirements 21.3.7. 


5.6.9 | When there are changes to the software safety requirements which affect the plan for the production of software, the plan is to 
be revised. 


5.6.10 The production of software is to be performed in accordance with the Software Production Standard and the plan for the 
production of software. 


5.6.11 Where software code is automatically produced by tools, the tools are to be shown to be suitable for use based on the risk that 
tool outputs may pose, and on any requirements of the Software Production Standard. The software producer's verification processes 
are to include the production of verification evidence that is to be provided to LR as part of the justification required by 
Vol 2, Pt 9, Ch 8, 5.6 Programmable electronic systems — Additional requirements for the production of software 5.6.3. 


5.6.12 Where the software development includes the use of previously developed software, the plan for the development of the software 

is to include: 

(a) defined software modification processes which are to be part of the supplier's quality management system; 

(b) assessment of the impact of the modification on the previously developed software modules, which is to be used to tailor the producer 
of software’s management systems for the specific software development modification; and 

(c) integration of any additional software safety requirements identified by the risk assessment required by Vol 2, Pt 1, Ch 3, 21.3 
Performance requirements 21.3.3, implemented through the configuration of the existing software, by providing new software to 
work in cooperation with the existing software, or by other means acceptable to LR. 


5.6.13 During the production of software, the producer of software is to actively maintain the system safety analysis required by Vol 2, 
Pt 1, Ch 3, 21.3 Performance requirements 21.3.2 to ensure that emerging properties of the software are assessed. Changes in the 
system safety analysis are to be documented, endorsed by the System Design Authority and mitigated through derived software safety 
requirements. 


5.6.14 The system safety analysis documentation recording the hazards, the software safety requirements and the traceability between 
them is to be updated to include any additional hazards emerging from the re-evaluation analysis required by Vo! 2, Pt 9, Ch 8, 5.6 
Programmable electronic systems — Additional requirements for the production of software 5.6.13. This documentation is also to be 
updated when the system hazard requirements are changed, added or removed. 


5.6.15 Where it is not possible to implement the original software safety requirements, or where updates are necessary as a result of 
additional system safety hazards, the producer of software is to communicate this to the System Design Authority and other affected 
stakeholders and the software safety requirements are to be re-evaluated in accordance with Vo/ 2, Pt 1, Ch 3, 21.3 Performance 
requirements 21.3.1. 
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5.6.16 Where modified software is to be used in the implementation of an engineering system, the engineering and safety justification 
required by Vol 2, Pt 9, Ch 8, 5.6 Programmable electronic systems — Additional requirements for the production of software 5.6.3 is to 
include: 

(a) why the modified and unmodified parts of the software are fit for purpose; 

(b) how the system hazard requirements are satisfied by the software; and 

(c) reference to evidence, both available and to be derived during the software production process, that supports the justification. 


5.6.17 Where existing software is to be used in the implementation of an engineering system, the engineering and safety justification 
required by Vol 2, Pt 9, Ch 8, 5.6 Programmable electronic systems — Additional requirements for the production of software 5.6.3 is to 
include: 

(a) why the existing software is fit for purpose; 

(b) how the system hazard requirements are satisfied by the existing software; and 

(c) reference to evidence, both available and to be derived during the production process, that supports the justification. 


5.6.18 Where software has been previously assessed and certified and the justification for the suitability of the software relies on the 

previous certification, the engineering and safety justification required by Vol 2, Pt 9, Ch 8, 5.6 Programmable electronic systems — 

Additional requirements for the production of software 5.6.3 is to demonstrate why the existing certification is applicable to the proposed 

application. Evidence is to be submitted justifying the applicability of the software for the specific application, which is to include but is 

not to be limited to: 

(a) the configuration(s) of the previously certified software; 

(b) the operating scenario relevant to the previously certified software; 

(c) the standard against which the previous certification was based; 

(d) the applicability of any expected level of risk reduction that was previously certified; 

(e) the relevance of any conditions of use placed upon the certified software; 

(f) copies of the previous certification for the software; 

(g) asummary of modifications and updates to the software since the issue of the previous certification; and 

(h) analysis demonstrating that the degree of reliance that can be placed on the software achieving its safety requirements is less than 
or equal to that against which it was previously certified. 


5.6.19 Where software has been previously used with development data available, and the justification for suitability of the software 

relies on the development data, the engineering and safety justification required by Vo/ 2, Pt 9, Ch 8, 5.6 Programmable electronic 

systems — Additional requirements for the production of software 5.6.3 is to include, but is not to be limited to, the following evidence: 

(a) The evidence supporting the argument is to be for the same software version as that of the proposed application. 

(b) The producer of software is to provide access to the development data so that LR can assess the level of compliance of existing 
software with the rules. 

(c) Where the production of software has included the use of sub-contractor(s), the producer of software is to facilitate access to data 
held by the sub-contractor(s). 

(d) The argument is to identify any additional assurance activities that are necessary to verify that the software safety requirements 
have been satisfied. 


5.6.20 Where software has been previously used with previous-use data available, and the justification for suitability of the software 

relies on the previous-use data, the engineering and safety justification required by Vol 2, Pt 9, Ch 8, 5.6 Programmable electronic 

systems — Additional requirements for the production of software 5.6.3 is to include, but is not to be limited to, the following evidence: 

(a) The use of the software under the same conditions as the proposed application including, but not limited to, running on the same 
hardware and operating system (if applicable), and having the same functional requirements. 

(b) The producer of software is to provide access to the development data so that LR can assess the level of compliance of existing 
software with the rules. 

(c) Where the software under assessment provides only part of an engineering system’s software solution, the production of software 
is to include validation of the software module as part of the total software solution. 


5.6.21 The System Design Authority is to create during the ship's design and construction phase a registry of all programmable 
electronic systems, logical (virtual) servers, desktops and network communication devices installed on board the ship, identifying the 
hardware and software installed within. 


5.6.22 The System Design Authority is to maintain the registry required by Vo/ 2, Pt 9, Ch 8, 5.6 Programmable electronic systems — 
Additional requirements for the production of software 5.6.21 and make it available to the Surveyors on request. The registry is to record 
all changes made to the ship's equipment during the ship's operational life, detailing as appropriate: 

(a) system; 

(b) vendor; 

(c) system version; 

(d) configuration version; 

(e) date tested; 

(f) test record reference; 

(g) plan for production of software document reference; 

(h) static network address; and 

(1) records of reasons for the changes including details of any alterations to software functionality. 


5.6.23 Where remote access features or facilities for enabling temporary connections with external devices are included for the 
programmable electronic system, the System Design Authority is to periodically review the provisions made within the hardware and 
software to ensure that new vulnerabilities and dependencies have not occurred or have been adequately addressed to mitigate the risk 
related to their possible exploitation. 
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5.6.24 The through-life management of the software is to be undertaken by the System Design Authority in accordance with an 
acceptable process for the maintenance of software. The process to be applied is to consider changes to the context of use and/or 
amended software in the same manner as the originally developed software by applying the plans and standards required by these 
Rules. Alternative processes acceptable to LR may be applied to the software maintenance activities. The System Design Authority may 
delegate the through-life management of software to the software producer or other organisation when undertaking software 
modifications. See also Vol 2, Pt 9, Ch 1, 1.7.3 Alterations and additions. 


Volume 2, Part 12 
Chapter 1 
Emissions Abatement Plant for Combustion Machinery 


= Section 10 
Storage and use of chemicals 


10.2 Chemical treatment fluids used for exhaust gas cleaning systems (EGCS) 


10.2.1 The aqueous solution of sodium hydroxide (NaOH) or calcium hydroxide (Ca(OH)z2) is commonly used as a chemical treatment 
fluid used for EGCS. Where other chemical treatment fluids are used, safety measures are to be taken according to the result of a risk 
assessment conducted to analyse the risks, in order to eliminate or mitigate the hazards to personnel on board the ship. 


10.2.2 The storage tank for chemical treatment fluid is to be arranged so that any leakage will be contained and prevented from making 
contact with heated surfaces. All pipes and other tank penetrations are to be provided with manual closing valves attached to the tank. 
In cases where such valves are provided below the top of tank, they are to be provided with quick closing valves which are to be capable 
of being remotely operated from a position safely accessible in the event of chemical treatment fluid leakage. Tank and piping 
arrangements are to be approved. 


10.2.3. The storage tank for chemical treatment fluid is to be protected from excessively high or low temperatures applicable to the 
particular concentration of chemical treatment fluids. Depending on the operational area of the ship, this may require the fitting of heating 
and/or cooling systems. 


10.2.4 If astorage tank for chemical treatment fluid is installed in a closed compartment, then the area is to be served by an effective 
mechanical ventilation system of the extraction type, providing not less than 6 air changes per hour, which is independent from the 
ventilation system of accommodation, service spaces, or control stations. The ventilation system is to be capable of being controlled from 
outside the compartment. A warning notice requiring the use of such ventilation before entering the compartment shall be provided 
outside the compartment adjacent to each point of entry. 


10.2.5 The requirements specified in Vol 2, Pt 12, Ch 1, 10.2 Storage and use of chemicals 10.2.4 also apply to closed compartments 

normally entered by persons: 

(a) when they are adjacent to the integral storage tank for chemical treatment fluid and there are possible leak points (e.g. manhole, 
fittings) from these tanks; or 

(b) when the treatment fluid piping systems pass through these compartments, unless the piping system is made of steel or other 
equivalent material with melting point above 925°C and with fully welded joints. 


10.2.6 The storage tank may be located within the engine room. In this case, a separate ventilation system is not required when a 
general ventilation system for the space providing not less than 6 air changes per hour is arranged so as to provide an effective movement 
of air in the vicinity of the storage tank and is maintained in operation continuously except when the storage tank is empty and has been 
thoroughly ventilated. 


10.2.7 Each storage tank for chemical treatment fluid is to be provided with level monitoring arrangements and high/low level alarms. 
In cases where heating and/or cooling systems are provided, high and/or low temperature alarms or temperature monitoring are also to 
be provided. 


10.2.8 The storage tanks are to have sufficient strength to withstand a pressure corresponding to the maximum height of a fluid column 
in the overflow pipe, with a minimum of 2,4 m above the top plate, taking into consideration the density of the treatment fluid. 


10.2.9 Where chemical treatment fluid is stored in integral tanks, the following are to be considered during their design and construction: 

(a) these tanks shall be designed and constructed as an integral part of the hull (e.g. double bottom, wing tanks); and 

(b) these tanks shall be coated with appropriate anti-corrosion coating and are to be segregated by cofferdams or other similar spaces 
from accommodation, cargo spaces containing cargoes which react with chemical treatment fluid in a hazardous manner, food 
stores, oil tanks, lube oil tanks, aviation fuel tanks or fresh water tanks. 


10.2.10 The chemical treatment fluid piping and venting systems are to be independent of other ship piping systems. The chemical 
treatment fluid piping systems are not to be located in accommodation, service spaces, or control stations. The vent pipes of the storage 
tank are to terminate in a safe location on the weather deck and the tank venting system is to be arranged to prevent entrance of water 
into the tank for chemical treatment fluids. 
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10.2.11 Storage tanks and piping systems for chemical treatment fluids which transfer undiluted chemical treatment fluids are to be of 
steel or other equivalent material with a melting point above 925°Celsius. 


10.2.12 Storage tanks and piping systems for chemical treatment fluids are to be made with a material compatible with the chemical 
treatment fluids, or coated with appropriate anti-corrosion coating. 


10.2.13 Regardless of design pressure and temperature, piping systems containing chemical treatment fluids are to comply with the 
requirements applicable to Class | piping systems. 


10.2.14 The detachable connections between pipes or pipe and equipment are to be screened and fitted with drip trays to contain any 
spillage. The drip trays are to be fitted with drainpipes which lead to a residue tank. Tanks are to be fitted with high level alarm or are to 
be fitted with alarms for leakage detection. Where a tank is an integral tank, the requirements of Vol 2, Pt 12, Ch 1, 10.2 Storage and use 
of chemicals 10.2.8 are to be applied. 


10.2.15 For the protection of crew members, the ship is to have on board suitable personnel protective equipment consisting of protective 
clothing, boots, gloves and tight-fitting goggles. The amount of personnel protective equipment carried on board is to be appropriate for 
the number of personnel engaged in regular handling operations or that may be exposed in the event of a failure; but in no case are there 
to be less than two sets available on board. 


10.2.16 Eyewash stations and safety showers are to be provided; the location and number is to be appropriate for the location of 
chemical treatment fluid systems on board. The following locations are to be provided as applicable; 

(a) transfer or treatment pump locations; 

(b) chemical bunkering station on deck; 

(c) system connections/components that require periodic maintenance; and 

(d) any part of the system where a spillage/drainage may occur. 


10.2.17 Storage tanks for chemical treatment fluids are to be arranged so that they can be emptied of the fluids and ventilated by means 
of portable or permanent systems. 


10.2.18 The holding tanks for residues generated from the exhaust gas cleaning process are to satisfy the following requirements: 

(a) The tanks are to be independent from other tanks, except in cases where these tanks are also used as the overflow tanks for 
chemical treatment fluids storage tank. 

(b) Tank capacities are to be decided in consideration of the number and type of installed exhaust gas cleaning systems as well as the 
maximum number of days between ports where residue can be discharged ashore. In the absence of precise data, a figure of 30 
days is to be used. 

(c) Where residue tanks used in closed loop chemical treatment systems are also used as the overflow tanks for chemical treatment 
fluid storage tanks, the requirements for storage tanks apply. 
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